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(54) Expanded smart card communication architecture and procedure for communicating 
between smart card application and data carrier 

(57) The present invention describes an Improved 
communication architecture for smart card systems and 
an improved procedure for communication of the smart 
card applications using protected data cam'ers, particu- 
larly in the case where smart cards or smart card read- 
ers cannot be used. The inproved communication 
architecture has a common virtual smart card interface 
between the respective smart card applications and the 
modules which facilitate access to the protected data 
can'iers (smart cards). The modules allow access to 
either physical smart cards, virtual software smart cards 
or hardware smart cards. The common virtual smart 
card interface means that the application is completely 
independent of the respective module or the respective 
data carrier. Alternatively, the irrproved communication 
architecture additionally contains a virtual sn>art card 
adapter which communicates over the common virtual 
smart card interface witti the respective smart card 
application. The different modules are attached to ttie 
smart card adapters and selected statically or dynami- 
cally over the smart card application. Virtual software 
smart cards which functionally imitate true physical 
smart cards can be linked over ttie virtual smart card 
adapter to communicate with a smart card application. 
This procedure is then particularly suited for when the 
smart card is lost or defective, ttie smart card reader 
cannot function, a for testing new smart card technolo- 
gies. 
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Description 

[0001 ] The present Invention descra^es an expanded 
smart caid architecture for convnunicatong between the 
smart card application and a data carrier, particularty In 
the case where the smart card a the smart card reader, 
lor whatever reason, is not present or cannot be used. 
[0002] With the Introduction of new technology and 
programs which necessitate the use of smart cards, the 
problem of short term availability of smart card readers 
often arises. Workstations for users must be converted 
to new smart card readers which conform to this tech- 
nology. This Is often very laborious from a technical 
point of view and. particulariy in large companies, takes 
a great deal of tim& The result of this is that new tech- 
nologies or programs have to be operated together with 
old technologies and programs in a transitional phase. 
This is both cost and labour intensive. 
[0003] Defective smart card readers prevent transac- 
tk>ns using the smart card. This can be economically 
disadvantageous both for the smart card owner as well 
as for the operator of the smart card reader, depending 
on the field of use. 

[0004] In the case of a smart card being lost, the 
owner is prevented from working with the smart card 
until a new card is issued. In certain cases, e.g. during 
long trips away, this can lead to problems for the owner. 
This is increasingly the case because many business 
activities are extensively carried out using smart cards. 
[0005] it is therefore tite task of tiie present invention 
to produce a procedure and system which is able to 
avoid the above mentioned disadvantages. 
[0006] The task is solved by the features of claims 1 . 
20 and 30. Additional advantageous embodiments are 
presented in the sub-claims. 
[0007] The advantages of the present invention are 
that a virtual software smart cafd can be used instead of 
a physical smart card. The virtual software smart card 
represents a pure software solution and is modelled on 
the functions of a physical smart card. The testing of 
new smart card solutions is limited to the testing of the 
virtual software smart card. The creation of a virtual 
software smart card, based on a new smart card solu- 
tion, is less time consuming and thus also cheaper than 
creating a smart card. Laborious smart card prototypes 
for testing the newly developed smart cards thus 
become unnecessary. In the case of loss of the physical 
smart card, ttie person entitied to do so can download a 
virtual software smart card using a diskette or over the 
Net into his system and continue to work using this vir- 
tual software smart card until a new smart card is 
issued. 

[0008] Organisatfons and companies can use new 
sntart card technology by making available virtual soft- 
ware smart cards, without all the systems having to be 
equpped already with new smart card readers. For 
smart card manufacturers, the advantage is tiiat new 
technologies can be tested in the later application envi- 



ronment befae components (such as aypto-coproces- 
sors, large memories, etc.) are available. 
[0009] By introducing a common virtual smart card 
interlace and a virtual smart card adapter, communica- 

5 tion between ttie smart card application and the nxxi- 
ules of the virtual smart card adapter is completely 
independent. For the smart card application, it makes 
no differerKe with which nrxxlule of the virtual smart 
card adapter it is communicating. Modules are access 

10 routines on a physical smart card, a virtual software 
smart card or a hardware smart card with the f unctfon- 
ality of a smart card. Changes and amendments in ttie 
nxxJules or the virtual smart card adapter do not require 
any adaptation of the respective smart card application 

IS due to the common virtual smart card interface. 

[POI 0] The present invention wHI be explained in more 
detail using a preferred embodiment example and fig- 
ures where: 

20 Fig. 1 shows a communication architecture 
between smart card applications and smart cards 
or smart card modules 

Rg. 2 shows the communication architecture in 
25 accordance with the invention between different 
smart card applications and different data caniers. 

[0011] Fig. 1 describes a communication architecture 
between different smart card applications and different 

30 smart cards. The identif k»tion of the card is earned out 
by the application. The different applications communi- 
cate with specific smart card access routines over spe- 
cial interfaces (PKCS#11, CDSA, CAPI). The respective 
smart card access routines are eittier a part of ttie 

35 respective application or form a separate software com- 
ponent For different smart cards witti different operat- 
ing systems or different data structures, ttiey have their 
own access routines. Each new smart card or changes 
to the operating system software or data structure of a 

40 smart card requires an adaptation of tiie respective 
access functions. 

[0012] Fig. 2 describes ttie communication architec- 
ture in accordance with the invention between different 
smart card applications and different data carriers. Dif* 

45 ferent applications corvimunfoate over a common virtual 
smart card interface (VCS) witti ttie respective modules. 
Applfoations 1 and 2. for exanple. touch on a standard- 
ized interi^ce such as PKCS #11 and applk:ation 3 
touches on a standardized Interface such as CAPI. The 

so implementation of cfifferent standard interfaces (PKCS 
#1 1 . CDSA. CAPI) uses ttie common virtual smart card 
interface. Application 4 touches directiy on the common 
virtual smart card interfaca Preferak)ly. a virtual smart 
card adapter (VCS adapter) is arranged below ttie com- 

55 mon virtual interfaca 

[0013] The VCS adapter is a software module and 
offers a uniform Interface for all applications. Different 
modules (smart card modules, software smart card 
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mcdules. hardware card nxxiules) can be attached to 
the VCS ttlapter. The applications can intefrogate the 
accessible nmlules over the VCS adapter. The appfica- 
tion can oomnuinicate with a selected nrxxiule over the 
VCS adapter. The selection of the respective module 
can be canied out statically or dynamically. In the case 
of dynamic linking of a module, over the Net for exanv 
pie. the VCS adapter checks the identity and authentic- 
ity of the module, i.a whether the module has been 
created by an authorized entity and has not been modi- 
fied in the meantime. The nfKxiule receives a digital sig- 
nature which is tested by the VCS adapter on creating 
the oommunk»tion. The VCS. too. can also be con- 
nected statically or dynanrvcally to the application. In the 
case of dynamic connections, the smart card applica- 
tion checks the identity and autherttidty of the VCS 
adapter. Therefore, even the applicatfon can be linked 
dynamk»lly to the VCS adapter over the Net. 
[0014] Also^ in this case the identity and authenticity 
of smart card applications nust be checked. The check 
here on authenticfty Is also carried out using a digital 
signature. 

[0015] Alternatively, the smart card applicatxyi. the 
VCS adapter and also the modules attached to it can be 
linked statically In this case, a digital signature is 
unnecessary. 

[0016] . Modules are the access routines to the data 
objects; the data objects can, for example, be stored in 
a physical or a virtual smart card or on a hardware 
smart card. Cryptographic functions are filed either in 
the module or on a physical smart card or a hardware 
smart card (ag. PCM/CIA card) . In the case of a virtual 
software smart card, the cryptographk; functions bxb a 
part of the virtual software smart card. 
[001 7] Access to private data on a physical smart card 
or hardware smart card is protected by a password (ag. 
PIN). 

[0018] With the virtual software smart cards, private 
data is additionally encoded with the support of the 
password. The codes of the virtual software smart cards 
are additionally protected, particularly against being 
read out. 

[0019] Several standardized virtual software smart 
card types can be developed and stored on a stc^ge 
medium; the virtual software smart cards can also be 
distrixited over the Internet to users. Virtual software 
snfiart cards have a generic structure and do not contain 
any user-specific data. They simply represent the 
method of finctioning of a physical smart card. There- 
fore, they need to be initialized^ersonalized by the user. 
The initialization of the virtual software smart card pref- 
erably precedes an authentication procedure whfoh 
establishes whether changes have been made in the 
virtual software smart card in the transmission of the vir* 
tual software smart card from one system to the other. 
The virtual software smart card preferably equi3ped 
with a user interface for initializing the virtual smart 
card. The user Interface asks the user, for exampla 



which virtual software smart card type is required. 
Smart card types cover, for exampla signature cards, 
access cards or data carda The user interface aste the 
user to determine a password or to accept or change an 

5 existing password. The virtual software smart card gen- 
erates a code from the password. From the informatfon 
requested, a memory area is established on the hard 
disk of the user for storing public data ot>jects and a 
memory area for storing private data objects. This is 

10 carried out by functions of the virtual software smart 
card. Components of the virtual software smart card are 
the access routines on the data ok^ects which are 
stored on the hard disk. The public data otjects are 
freely accesstsle; private data objects can only be 

IS accessed using a code4)assword. The user Is Me to 
wori( using the virtual software smart card. 
[0020] The VCS adapter can be a component of the 
virtual smart card or* can represent its own software 
component which is made available together with the 

20 virtual software smart card. 

Claims 

1. Conrminication architecture for the exchange of 
25 informatfon between a smart card application and a 

protected data carrier oorrtaining at least the folkiw- 
ing components; 

a) a smart card application 

30 

b) a virtual smart card adapter with a common 
interface to all smart card applications for link- 
ing in modules for access to protected data car- 
riers 

35 

c) a nxxjule with access routines to a protected 
data carrier 

d) a data carrier with private and public data 
40 objects where the private data can be pro- 
tected against access. 

2. Conrminication architecture in accordance with 
claim 1, characterised in that the module Is able to 

45 be connected statically to the smart card adapter. 

3. Communication architecture in accordance with 
claim 1, characterised in that the module is able to 
be connected dynamically to the smart card 

50 adapter. 

4. Communication architecture in accordance with 
daim 3. characterised In that the module is ab^e to 
be connected dynamically with the smart card 

55 adapter over the Net 

5. Communication architecture in accordance with 
claims 3 or 4. characterised in that the nxxJule 
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which can be selected dynamicaily is able to have 
its Identity and/or authenticity checked by the smart 
card adapter. 

6. Communication architecture in accordance with s 
claims 3 to 5. characterised in that the authenticity 

of the module is able to be checked by a digital sig- 
nature. 

7. Communication architecture in accordance with io 
claims 1 to 6. characterised in that the smart card 
adapter is able to be connected statically with the 
smart card application. 

8. Communication-architecture in accordance with is 
claims 1 to 6. characterised in that the smart card 
adapter is able to be connected dynamically to the 
smart card applicatioa 

9. Communication architecture in accordance with 20 
claim 8, characterised in that the smart card 
adapter is able to be connected dynamically over 
the Net to the smart card application. 

10. Communication architecture in accordance with 25 
claims 8 and 9, charactersied In that the smart card 
adapter which can be connected dynamically is 
able to have its identity and/or authenticity checked, 

by the smart card application. 

30 

11. Communication architecture in accordance with 
claims 8 to 10, characterised in that the authenticity 
of the smart card adapter is able to be checked 
using a digital signatura 

35 

12. Convnunication architecture in accordance with 
claims 1 to 11, characterised in that the modules, 
which are able to be connected to the smart card 
adapter over the smart card application program, 
are able to be interrogated, selected and oon- 40 
nected. 

13. Communication architecture in accordance with 
claims 1 to 12, characterised in that the protected 
data carrier is a physical smart card, a virtual soft- 45 
ware smart card or a hardware smart card with the 
functionality of a smart card. 

14. Communication architecture in accordance with 
claims 1 to 13, characterised In that the virtual soft- so 
ware smart card is able to be connected dynami- 
cally or statically to the respective module. 

15. Communication architecture In accordance with 
claims 1 to 14, characterised In ttiat the identity ss 
and/or authentk;lty of the virtual software smart' 
card is able to be checked by the nrxxJuIa 



16. Convnunication architecture in accordance with 
claims 14 to 15. characterised in that the test of 
authenticity of the virtual software smart card which 
can be connected dynamically is carried out using a 
digital signature. 

17. Communication architecture in accordance with 
daims 1 to 16. characterised in that the virtual soft- 
ware smart card is able to be initialized and person- 
alized. 

18. Communication architecture In accordance with 
daims 1 to 17, characterised in that data objects 
are able to be f Oed on the data carrier through func- 
tions of the virtual software smart card and access 
to the data objects by the module are able to be cre- 
ated using functions of the virtual smart card. 

ia Communication architecture In accordance with 
daims 1 to 18, characterised in tturt cryptographk: 
furKtions for coding and encoding data are part of 
ttie virtual software smart card. 

2a Communication architecture for the exchange of 
information between a smart card application and a 
protected data earner containing at least the fbllow- 
ing conponents: 

a) a smart card application 

b) a module with access routines to a protected 
datacanier 

c) a virtual software smart card witii crypto- 
graphic functions for fling, reading and writing 
data objects on a data carrier 

d) a data carrier on which data objects with pri- 
vate and public data can be stored, whereby 
private data can be protected against access 
using the virtual software smart card. 

21. Communication architecture in accordance with 
daim 20, characterised in that the module Is able to 
be connected statically or dynamically to the smart 
card application. 

22. Communication architecture In accordance with 
daim 21. characterised In ttiat in the case of 
dynamic connection of the module witti the smart 
card applicatfon, its identity and/or authentidty is 
able to be checked using a digital signature. 

2a Communication architecture in accordance with 
daims 20 to 21, characterised in that ttie virtual 
software smart card is able to be connected stati- 
cally or dynamically to the module. 
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24. Communication architecture in accordance with 
daim 23. characterised in that in the case of 
dynamic connection of the virtual software smart 
card to the module, its Identity and/or authenticity is 
at)ie to be checked using a digilal signature. § 

25. Communication architecture in accordance witii 
claims 20 to 24. characterised in that a virtual smart 
card adapter with an interface common to all smart 
card applications for linking modules for access to io 
protected data cam'ers is additionally able to inte- 
grated. 

26. Communication architecture in accordance with 
claim 25. characterised in ttiat the smart card is 
adapter is able to be connected dynamically to the 
smart card appficatioa 

27. Communication architecture in accordance with 
claim 26, characterised in ttiat the smart card so 
adapter is able to be connected dynamk»lly over 
the Net to the smart card application. 

28. Communication architecture in accordance with 
claims 25 and 26, characterised in that ttie smart 2S 
card adapter which can be connected dynamically 

is able to have its identity and/or auttienticity 
checked by ttie smart card application. 

29. Communication architecture in accordance with 30 
claims 25 to 28, characterised in ttiat the modules 
whk:h can be connected to the smart card adapters 
are able to be interrogated, selected and connected 
over ttie smart card application program. 

3S 

30. Procedure for implementing virtual software smart 
cards where ttie software smart cards functionally 
imitate physical smart cards, characterised by the 
fbllowing steps: 

40 

a) the offering of a user-interface for the selec- 
tion of types of virtual software smart cards 
which are filed on a storage medium 

b) the selection of a virtual software smart card 4S 
in accordance with step a) by the user 

c) the personalizing of the virtual software 
smart card by the user entering a password 

so 

d) ttie generation of private and public data 
objects on a storage medium using software 
smart card functions 

e) ttie availability of access functions to the ss 
data ot)jects using software smart card func- 
tions where private data objects are protected 
from unauttiorized access. 
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